\documentclass[titlepage]{article}
\usepackage[usenames,dvipsnames,svgnames,table]{xcolor}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[italian]{babel}
\usepackage{etoolbox, mathptmx, anyfontsize, t1enc, graphicx}
\usepackage[space]{grffile}
\usepackage{titlesec, hyperref, ltablex, array}
\usepackage[margin=1.25in]{geometry}
\usepackage{float}
\usepackage{lscape}
\usepackage{pdfpages}
\definecolor{light-gray}{HTML}{EEF2F7}
\definecolor{light-blue}{HTML}{C5D3FF}
\definecolor{mauve}{HTML}{E0B0FF}

%code highlight e import
\usepackage{verbatim, listings}

% Packages per i sequence diagrams
\usepackage{tikz, tikz-uml}
\usepackage{pgf-umlsd}
\usepgflibrary{arrows}
\usetikzlibrary{arrows,shadows}

\makeatletter
\patchcmd{\@maketitle}{\Huge}{\huge}{}{}
\makeatother

\hypersetup{
	colorlinks,
	citecolor = black,
	filecolor = black,
	linkcolor = blue,
	urlcolor = red
}

\hyphenation{ac-cor-da-re ma-nie-ra u-ni-vo-ca do-cu-men-to svi-lup-po
cal-co-la-ta sot-tra-en-do i-nat-ti-vi-tà men-si-le ser-vi-zio ap-pli-ca-ti-vo
pre-e-sis-ten-te ri-guar-do ap-pli-ca-zio-ne sup-por-to hard-ware di-vi-so
mi-nu-ti}

%Profondità degli indici di numerazione delle sezioni
\setcounter{secnumdepth}{4}

\titleformat{\paragraph}
{\normalfont\normalsize\bfseries}{\theparagraph}{1em}{}
\titlespacing*{\paragraph}
{0pt}{3.25ex plus 1ex minus .2ex}{1.5ex plus .2ex}

\title{
	\includegraphics[scale=0.13]{PoliMI.png}\centering\\
	\fontsize{50}{60}\selectfont Travel Dream\\
	\fontsize{20}{30}\selectfont Progetto di Ingegneria del Software 2\\
	\fontsize{30}{50}\selectfont {\sffamily\scshape \textmd{D}esign \textmd{D}ocument\\}
\author{
	A. Rigamonti\\
	E. Tironi\\
	F. Zoffoli}
\date{}
}

\begin{document}
\def\arraystretch{1.2}
\maketitle
\tableofcontents
\newpage

\section{Introduzione}
In questo documento si illustrano le fondamenta su cui si basa l'applicativo
TravelDream. Lo scopo di tutta la documentazione è stato di rendere più chiara
ed esplicita possibile ogni scelta progettuale e la struttra che poi avrà
l'applicazione. Al contempo si è anche tentato di non rendere troppo pesante, e
quindi difficile da capire, i vari diagrammi, per cui si
incontraranno notazioni o semplificazioni (un esempio e il non ripetere gli
attributi all'interno delle entities nel documento BCE poichè gia presenti
dei modelli di navigazione) che a livello pratico non modificano il risultato
progettuale ma ne semplificano ampiamente la struttura.
Questo documento vuole risultare un'esplorazione a 360 gradi di come TravelDream
funzionerà: vengono per cui mostrati il flow e lo storage dei dati con la loro
strutturazione e la struttura delle pagine e dei controlli che averranno per
rendere l'applicazione interattiva e funzionale.
\newpage

\section{Design dei Dati}

\subsection{Modello Entity-Relationship}
Le entità di primo piano all'interno del sistema sono {\em Utente}, i {\em
Pacchetti} e i {\em Prodotti} che li compongono.
L'entità Utente si divide in {\em Registrato} o {\em Impiegato} per
differenziare i ruoli che hanno nell'uso dell'applicazione.
Prodotto invece viene suddiviso in {\em Hotel}, {\em Tour} e {\em TrattaVolo},
ovvero le componenti di un Pacchetto, infatti l'entità Pacchetto è collegata
dalle relazioni {\em Alloggia}, {\em Partecipa} e {\em ViaggiaCon}
rispettivamente a Hotel, Tour e TrattaVolo. Il Pacchetto inoltre è in relazione
con Impiegato tramite {\em CreatoDa}.\\
L'entità Pacchetto è distinta dall'entità {\em Pacchetto Personalizzato} il
quale ha una relazione {\em PossedutoDa} con Utente Registrato e, poiché si
differenzia da Pacchetto anche per il fatto di essere stato prenotato, è legato
alle tre entità che rappresentano le prenotazioni dei prodotti: {\em
PrenotazioneVolo}, {\em PrenotazioneTour} e {\em PrenotazioneHotel};
quest'ultime entità contengono i dettagli delle prenotazioni e sono legate a Hotel, Tour e TrattaVolo.\\
A Tour e Tratta volo vengono specificate le località che interessano questi due
tipi di prodotti: {\em Località} è un'entità in relazione con Tour e con
{\em Aeroporto} (si è scelto di utilizzare un'unica entità e di porla in
relazione (0,n)), quindi Aeroporto possiede due relazioni, {\em Da} e {\em A},
con TrattaVolo, alla quale viene specificata anche la compagnia con la quale
verrà effettuato il volo, introducendo una relazione con l'entità
{\em Compagnia}.
Si è scelto di modellare la compagnia come una entità e non come attributo di TrattaVolo in quanto ci sono poche compagnie che effettuano molti voli e perché si riferiscono a cose diverse e non sono logicamente correllate.\\
Le ultime entità che restano da discutere sono quelle relative alla {\em
GiftList}: si usano tre differenti entità, ognuna per ogni tipo di prodotto
(volo, tour, hotel), questo perché è possibile comprare una singola componente all'amico.
Ogni entità delle GiftList è in relazione con un Pacchetto Personalizzato e con
le corrispondenti prenotazioni di prodotti che l'utente vorrebbe: GiftListVolo
con PrenotazioneVOlo, etc..).
L'unica relazione che ogni tipo di Gift List ha con Utente è {\em Pagato Da}
(Volo Pagato Da, Tour Pagato Da, Hotel Pagato Da) che definisce chi compra uno dei prodotti.
Per evitare ridondanze si è scelto di non modellare la relazione di appartenenza di una gift list ad un utente in quanto si può ricavare da Posseduto Da tra Pacchetto Personalizzato e Utente Registrato.\\
\newpage
\includepdf[landscape, templatesize={25in}{10in}]{../DD/ER.jpg}
\newpage

\subsection{Ristrutturazione del modello ER}
Per poter riscrivere in modo corretto il modello concettuale abbiamo applicato
delle modifiche al modello logico ER rispetto al precedente modello, le
modifiche sono dovute al fatto che non tutti costrutti dell'ER hanno una
traduzione naturale al modello logico.\\

\begin{itemize}
  \item Sulla tabella PRODOTTO applichiamo un collasso verso il basso
  (top-down) eliminiamo l'entità padre trasferendo gli attributi sulle entità
  figlie TRATTA\_VOLO, HOTEL e TOUR. Applichiamo questa strategia perchè
  l'entità padre ha solo un attributo (IDProdotto) e una relazione (CreatoDa)  rispetto alle entità figlie che presentano un maggior numero di attributi di specializzazione.
  \item Sulla tabella PRODOTTO applichiamo un collasso verso il basso
  (top-down) eliminiamo l'entità padre trasferendo gli attributi sulle entità
  figlie TRATTA\_VOLO, HOTEL  e TOUR. Applichiamo questa strategia perché
  l'entità padre ha solo un attributo (IDProdotto) e una relazione (CreatoDa) rispetto alle entità figlie che presentano un maggior numero di attributi di specializzazione.
  \item La relazione ``viaggia con'' tra le tabelle PACCHETTO e TRATTA\_VOLO ha
  una cardinalità (2,2) per il pacchetto, per questo la relazione viene
  riscritta con 2 attributi uno di volo di andata e l’altra di volo di ritorno.
\end{itemize}


\subsection{Traduzione verso il modello logico}
Per il nostro progetto abbiamo deciso di tradurre alcune delle relazioni
(1,1)-->(0,N) utilizzando la chiave primaria della tabella con relazione (1,1) come attributo della tabella con relazione (0,N), ognuno di questi attributi lo chiameremo ID+nomeDellaTabella 
e nel modello logico sarà una chiave secondaria associata.\\

\begin{itemize}
  \item Ogni attributo IDImpiegato fa riferimento all'attributo IDUtente 
  	della tabella Utenti.
  \item Nella tabella TRATTA\_VOLO gli attributi Da e A fanno riferimento
  	all'IDAeroporto della tabella AEROPORTO.
  \item L'attributo Gruppo di appartenenza della tabella GROUP\_UTENTE possono
  	essere ``Impiegato'' per l'utente Impiegato e ``User'' per L'utente
  	registrato.
  \item Nella tabella TRATTA\_VOLO gli attributi ``Da'' e ``A'' fanno riferimento
  	all'IDAeroporto della tabella AEROPORTO.
  \item Nella tabella PACCHETTO\_PERSONALIZZATO l'attributo prenotazione sarà
  	un flag e potrà avere solo valori 0 per pacchetto nel carrello e 1 per
  	pacchetto personalizzato.
  \item La tabella PRENOTAZIONE\_VOLO ha come chiave primaria la combinazione
  	degli attributi IDPacchettoPers, IDVolo e Data.
  \item La tabella PRENOTAZIONE\_TOUR ha come chiave primaria la combinazione
  	degli attributi IDPacchettoPers, IDTour e Data.
  \item La tabella PRENOTAZIONE HOTEL ha come hiave primaria la combinazione
  	degli attributi IDPacchettoPers, IDHotel, checkin e checkout.
  \item Le tabelle per la gift list oltre ad avere un riferimento della
  	tabella PACCHETTO\_PERSONALIZZATO utilizzeranno questa relazione come chiave
  	primaria.
\end{itemize}

Elenchiamo quindi le varie tabelle con le rispettive chiavi primarie:\\

\begin{itemize}
	\item[] UTENTE ( \underline{IDUTente}, Nome, Cognome, email, password)
	\item[] GROUP\_UTENTE (\underline{IDUtente}, GruppoAppartenenza)
	\item[] LOCALITA ( \underline{IDLocalita}, Nome, Descrizione, Provincia, Stato)
	\item[] COMPAGNIA ( \underline{IDCompagnia}, Nome)
	\item[] AEROPORTO (\underline{IDAeroporto}, Nome, IDLocalità)
	\item[] TRATTA\_VOLO (\underline{IDVolo}, IDCompagnia, Da, A, IDImpiegato)
	\item[] TOUR (\underline{IDTour}, IDLocalita, Descrizione, Tipo, IDImpiegato)
	\item[] HOTEL (\underline{IDHotel}, Nome, IDLocalita, Via, NumeroCivico,
		IDImpiegato)
	\item[] PACCHETTO (\underline{IDPAcchetto}, IDHotel, IDTour, Pubblico(0,1),
		IDImpiegato)
	\item[] PACCHETTO\_PERSONALIZZATO (\underline{IDPacchettoPers}, IDCliente,
		Prenotazone(0,1))
	\item[] PRENOTAZIONE\_VOLO (\underline{IDPacchettoPers}, \underline{IDVolo},
	\underline{Data}, OraArrivo, OraPartenza, NumPosti)
	\item[] PRENOTAZIONE\_TOUR (\underline{IDPacchettoPers}, \underline{IDTour},
	\underline{Data}, NumPersone)
	\item[] PRENOTAZIONE\_HOTEL (\underline{IDPacchettoPers}, \underline{IDHotel},
	\underline{checkIN}, \underline{checkOUT}, NumPosti) 
	\item[] GIFT\_LIST\_HOTEL (\underline{IDPacchettoPers}, IDPagante,
		\underline{IDHotel})
	\item[] GIFT\_LIST\_TOUR (\underline{IDPacchettoPers}, IDPagante,
		\underline{IDTour})
	\item[] GIFT\_LIST\_VOLO (\underline{IDPacchettoPers}, IDPagante,
		\underline{IDVolo})

\end{itemize}
\newpage
\includepdf[landscape]{../DD/er2.png}
\newpage

\section{Design dell'Applicazione}
\subsection{Livelli Architetturali}
Per la realizzazione del sistema si utilizza Java Enterprise Edition come infrastruttura di supporto.\\
L'utente utilizza l'applicazione tramite un browser web supportato, di conseguenza non si necessita di alcun 
client specifico da installare e le richieste al server verranno effettutate
tramite HTML. Sul server sono presenti la logica applicativa e i beans per l'interfacciamento al database.\\
Per la memorizzazione dei dati si utilizzerà un database MySQL.\\
In conclusione i livelli dell'applicaziono saranno: Client Tier, Web Tier e Business Tier (Java EE Server) e 
Data Tier (Server Database).\\
\includegraphics[scale=1]{../DD/Tiers.png}

\newpage
\subsection{Modello di Navigazione}
Per semplicità di lettura il modello è stato diviso in 3 parti: Login, Cliente e
Impiegato. La ragione di questa scelta è che non c'è interoperabilità tra il
modello del cliente e dell'impiegato, per cui dividerle semplifica la lettura.
Poichè entrambe le pagine invece possono venir utilizzate nella fase di login,
in essa compaiono entrambe.
Una notazione per semplificare il grafico il simbolo \$ viene utilizzato a lato
dei nomi delle classi di tipo Screen per indicare che sono raggiungibili da
tutte le altre pagine Screen presenti nel modello.

\subsubsection{Login}
Dalla Homepage si può registrarsi o eseguire il login.
Nel caso di errore nel login si viene riportati alla homepage con ora mostrato
l'errore avvenuto durante il login. Un messaggio viene anche mostrato quando
si effettua il logout.
Alternativamente, quando una registrazione avviene correttamente si viene
riportati alla homepage con un messaggio di conferma; ora si può passare al
login.
In base alle credenziali si viene ridiretti alla pagina da cliente o da
impiegato.\\
\begin{center}\includegraphics[width=\textwidth]{../DD/modello navigazione
- login.png}
\end{center}

\subsubsection{Cliente}
Una volta loggato e nella propria pagina personale, il cliente può vedere le
informazioni del suo profilo.
Da qui può accedere allo storico dei suoi pacchetti comprati (le prenotazioni),
all'elenco dei pacchetti che ha in carrello e in wishlist, oltre a poter
navigare le wishlist di un altro utente.
Può inoltre visualizzare le proposte attuali dell'agenzia, e personalizzare i
pacchetti prima di metterli nel carrello, dal quale può poi decidere di
acquistarli.\\
\begin{center}\includegraphics[width=\textwidth]{../DD/modello navigazione
- cliente.png}
\end{center}

\subsubsection{Impiegato}
Una volta loggato, l'impiegato può accedere alle sue 3 funzioni principali: la
gestione dei pacchetti offerti, dei prodotti offerti e degli utenti.
Dalla gestione dei prodotti può aggiungere, modificare o rimuovere prodotti.
Dalla gestione dei pacchetti può aggiungere, modificare o rimuovere pacchetti;
la modifica cosiste nell'aggiunta, modifica(cioè sostituire quello corrente con
un altro dello stesso tipo) o rimozione di prodotti per quel pacchetto.\\
\begin{center}\includegraphics[width=\textwidth]{../DD/modello navigazione
- impiegato.png}
\end{center}

\newpage

\subsection{Componenti - BCE}
I componenti sono stati modellati utilizzando un modello
Entity-Control-Boundary, questo ci permetterà di sviluppare l'applicazione
seguendo il pattern Model - View - Controller per poter modificare una delle
tre in modo indipendente dalle altre.\\
Nello schema, le boundary sono l'interfaccia (view) tramite la quale gli utenti
interagiscono con TravelDream; le control sono i mediatori tra l'interfaccia e i
dati, i quali sono modellati come entity.\\
Gli attributi delle entity non sono stati riscritti, ma sono gli stessi presenti
nel diagramma ER.\\
Le entità Pacchetto Personalizzato e Prodotto comprendono Volo, Tour e Hotel. Si
è evitato di inserire questi tre tipi di prodotti in quanto avrebbero le
stesse funzioni, pertanto abbiamo generalizzato in modo da ridurre il numero di
entity e di funzioni nelle control così da semplificare il modello.
\vspace*{-0.5 cm}
\begin{center}
\includegraphics[scale=0.55]{../DD/BCE.png}
\end{center}

\subsection{Diagrammi di sequenza}
\begin{itemize}
	\item Il diagramma riguarda il login di un utente registrato che effettua
	l'accesso coinvolgengo la <bounday> Home Page che richiama il <control>
	Autenticazione il quale verifica la validità nella entity Utente.\\
	\begin{sequencediagram}
			\newthread[light-blue]{usr}{UtenteRegistrato}
			\newinst[0]{bndHP}{<Bound>HomePage}
			\newinst[0]{cntrA}{<Cntr>Autenticazione}
			\newinst[0]{entUtente}{<E>Utente}
			\newinst[0]{bndPP}{<Bound>PaginaPersonale}
			\begin{messcall}
				{usr}{1.login()}{bndHP}
			\end{messcall}
			\begin{messcall}
				{bndHP}{2.checkUser()}{cntrA}
			\end{messcall}
			\begin{messcall}
						{cntrA}{3.getIDUtente()}{entUtente}
			\end{messcall}
			\begin{messcall}
						{usr}{4.navigaOfferte()}{bndPP}
			\end{messcall}
	\end{sequencediagram}
	
	
	\item Il diagramma riguarda la visualizzazione del carrello e la
	prenotazione di un pacchetto presente all'interno di esso.
	L'utente che vuole visualizzato coinvolge la <Boundary> Utente che richiama la <Control> Manage
	la quale recupera i dati dalla <Entity> PAcchetto Personalizzato e li visualizza all'utente.
	Quando l'utente prenota il pacchetto si attiva la <Boundary> la quale richiama la <Control>
	che collegandosi alla <Entity> ne modifica lo stato di prenotazione.\\
	
	\begin{sequencediagram}
			\newthread[light-blue]{usr}{UtenteRegistrato}
			\newinst[0]{bndPPP}{<Boundary>Utente}
			\newinst[0]{cntrA}{<Control>Manage}
			\newinst[0]{entCarrello}{<Entity>Pacchetto Personalizzato}
			\begin{messcall}
						{usr}{showPrenotazioni()}{bndPPP}
			\end{messcall}
			\begin{messcall}
						{bndPPP}{showPacchettoPersonalizzato()}{cntrA}
			\end{messcall}
			\begin{messcall}
						{cntrA}{getPacchettoPersonalizzato()}{entCarrello}
			\end{messcall}
			\begin{messcall}
						{cntrA}{viewDatiPacchettoPersonalizzato()}{usr}
			\end{messcall}
			\begin{messcall}
						{usr}{PrenotaCarrello()}{bndPPP}
			\end{messcall}
			\begin{messcall}
						{bndPPP}{modificaPacchetto()}{cntrA}
			\end{messcall}
			\begin{messcall}
						{cntrA}{UpdatePacchetto()}{entCarrello}
			\end{messcall}
	\end{sequencediagram}
	
	\item Descriviamo un impiegato che inserisce un prodotto
	all'interno del database, l'utente si trova sulla form dei dati di inserimento e
	richiama il salvataggio degli stessi. Viene coinvolta la <Boundary> Impiegato che
	richiama la <Control> AdminPages la quale effettua un update all'<entity>
	Prodotto.\\
	\begin{sequencediagram}
		\newthread[light-blue]{usr}{Impiegato}
		\newinst[0]{bnd}{<Boundary>Impiegato}
		\newinst[0]{cntr}{<Control>AdminPages}
		\newinst[0]{ent}{<Entity>Prodotto}
		\begin{messcall}
			{usr}{editProdotto()}{bnd}
		\end{messcall}
		\begin{messcall}
			{bnd}{editProdotto()}{cntr}
		\end{messcall}
		\begin{messcall}
			{cntr}{updateProdotto()}{ent}
		\end{messcall}
	\end{sequencediagram}

	\item Mostriamo un utente che condivide un pacchetto con un amico esterno.
	L'utente accede alla lista dei suoi pacchetti in carrello con showCarrello()
	chiamato dal <Boundary> Utente al <Control> Manage, che a sua volta interpella
	l'<Entity> Pacchetto Personalizzato. Una volta che si ha a disposizione
	l'elenco, l'utente può semplicemente chiamare dal boundary condividiConAmico()
	fornendo l'email perchè questa operazione venga eseguita dal control.
	\begin{sequencediagram}
		\newthread[light-blue]{usr}{UtenteRegistrato}
		\newinst[0]{bnd}{<Boundary>Utente}
		\newinst[0]{cntr}{<Control>Manage}
		\newinst[0]{ent}{<Entity>Pacchetto Personalizzato}
		\begin{messcall}
			{usr}{showCarrello()}{bnd}
		\end{messcall}
		\begin{messcall}
			{bnd}{showCarrello()}{cntr}
		\end{messcall}
		\begin{messcall}
			{usr}{condividiConAmico(email)}{bnd}
		\end{messcall}
		\begin{messcall}
			{bnd}{condividiConAmico(email)}{cntr}
		\end{messcall}
	\end{sequencediagram}
\end{itemize}
\end{document}